Signature reading was reaching the internet, and three guards could not see it - #4

…ot see it

ADR-19 promises zero outbound connections. Reading signatures broke it from the
day that code was written, and it took a new instrument to find out.

WHAT WAS MEASURED. tools/outbound-probe/outbound.ps1 runs the product and watches
the native modules the process loads and the sockets it holds. Three runs out of
three: `bws list --signatures`, `bws snapshot create` and the window all load
WINHTTP.dll, WS2_32.dll and DNSAPI.dll and open HTTP connections off this machine.
Plain `bws list` does none of it, so signature reading is the whole of the
difference. The far end was named from the DNS cache: certificates.intel.com.

WHY NOTHING CAUGHT IT. WTD_REVOKE_NONE turns revocation checking off and has
carried a comment naming ADR-19 for thirteen months. It does not stop the chain
engine fetching a certificate this machine does not hold. No reader of source or
of metadata can see that, because nothing in our code says it.

THE FIX, AND THE HALF THAT MATTERS MORE. WTD_CACHE_ONLY_URL_RETRIEVAL confines the
chain engine to what this machine already has, unless --follow-network is given -
the same switch that already decided whether a launch path on somebody else's
share may be opened. One promise, one control, and nobody gets more network than
they had before.

On its own that fix would have bought silence with a lie. A properly signed file
can come back non-zero once the engine may not go and look, and the classifier
would have turned our own refusal into UntrustedRoot - a claim about somebody's
certificate. So a verdict now survives the quiet mode only if it is a fact about
the file or its own certificate: Trusted, NotSigned, Expired, Tampered. Anything
about the chain to a root becomes a refusal carrying the system's number and
sentence, which is the shape binaryOnDisk already takes for a network path. No new
state, no schema change. Which code Windows actually returns in that case is NOT
VERIFIED - no file on the machine this was found on needed a fetch to reach its
verdict - and the design deliberately does not depend on it.

MEASURED WITH THE CERTIFICATE URL CACHE AND THE DNS CACHE CLEARED: 797 entries,
790 Trusted, 3 NotSigned, 790 publishers, identical before and after. 1.3 s
against 2.4 s. With --follow-network the fetch returns and so does the full
answer, which the probe now asserts as its own subject - a probe that only ever
checks for silence cannot tell a quiet product from a reader that reads nothing.

NEW GUARDS FOR THE FAMILY THIS BELONGS TO. A P/Invoke to winhttp.dll carries no
managed type reference, so the existing System.Net check cannot see one: measured
by declaring WinHttpOpen in the product, where that guard stays green on all three
projects while the new ones redden on three counts. OutboundGuards holds the
native modules our own assemblies may bind, the four libraries that ship beside us
- Wpf.Ui, Wpf.Ui.Abstractions, WinRT.Runtime, Microsoft.Windows.SDK.NET, all clean
- the Win32 inventory files, and the hand-written list of shipped projects that
every assembly-reading guard walks.

Bws.Core.Tests 635 -> 649, Bws.Architecture.Tests 69 -> 82. Eleven mutation
registry entries, all caught.

Co-Authored-By: Claude Opus 5 <[email protected]>

… guard

EMPTY REASON ON A REFUSAL. Settle handed string.Empty to Reading.Denied whenever
Marshal.GetExceptionForHR answered null, which it does for every non-negative
HRESULT. S_FALSE is 1, it reaches that line, and it was already in the list the
tests walk - they simply never asked about the sentence. A refusal with no
sentence is the shape rule 8 forbids wearing the shape of the thing it requires.
ManagerTerms.Describe is the fallback every other refusal in this project uses.
Shown red before the fix: result 0x00000001 carried no sentence at all.

THE TWO CANARIES COUNTED INSTEAD OF NAMING. A count of three native modules is
satisfied by three modules nobody expected, and a count of four libraries beside
the product is satisfied while the scan reads one output folder instead of two -
which is how that scan would actually break, losing Wpf.Ui. Both now name what
must be there and print what they found instead.

Two smaller ones. The changelog said "nothing was sent about your machine", which
is too generous: nothing was uploaded, but a connection carries an address and
which certificate is asked for says whose software is installed. And the Polish
wording on the site said "wyjsc poza" where "siegnac poza" reads properly.

While fixing the first finding, the assertion on the error code turned out to be
wrong in a way worth keeping: Reading unwraps a FACILITY_WIN32 HRESULT to its
Win32 code on the way in - 0x80070005 becomes 5 - because one refusal carrying
two different numbers for one fact has its own mutation entry. Asserting the raw
value would have quietly re-opened it.

Bws.Core.Tests 649 -> 650.

Co-Authored-By: Claude Opus 5 <[email protected]>